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(57) ABSTRACT 

A method for distributing Network Address Translator 
(NAT) translation table information among border routers 
associated with a routing domain using the Open Shortest 
Path First (OSPF) Opaque link State Advertisement (LSA) 
option protocol. The NAT translation table information is 
included in an application specific field following the LSA 
header. LS type 9 LSA packets are used to Limit the flooding 
scope to the local network segments attached to the border 
router. Network address information, i.e., local network 
address and corresponding global network address, are 
transmitted in the application specific field of the Opaque 
LSA packet. The Opaque LSA packets are exchanged 
between a group of interconnected Opaque LSA capable 
border routers so that the border routers can maintain 
identical NAT translation tables as necessary to forward data 
packets according to the NAT forwarding paradigm. 
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METHOD FOR SYNCHRONIZING 
NETWORK ADDRESS TRANSLATOR (NAT) 
TABLES USING THE OPEN SHORTEST 

PATH FIRST OPAQUE LINK STATE 
ADVERTISEMENT OPTION PROTOCOL 

COPYRIGHT NOTICE 

Contained herein is material that is subject to copyright 
protection. The copyright owner has no objection to the 
facsimile reproduction of the patent disclosure by any per- 
son as it appears in the Patent and Trademark Office patent 
files or records, but otherwise reserves all rights to the 
copyright whatsoever. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention is related to data communications. 
In particular, the present invention is related to a method for 
synchronizing Network Address Translator (NAT) tables, or 
databases, using the Open Shortest Path First (OSPF) 
Opaque Link State Advertisement (LSA) option protocol. 

2. Description of the Related Art 

The Transport Control Protocol/Interaet Protocol (TCP/ 
IP) suite of protocols is used in many of today's internet- 
works (internets). A TCP/IP-based internet provides a data 
packet switching system for communication between nodes 
(e.g., end-user workstations, servers, network devices, etc.) 
connected to an intemet. With reference to FIG. 1, in 
accordance with the well known International Standards 
Organization (ISO) Open Systems Interconnection (OSI) 
seven-layer conceptual model for data networking. Network 
layer devices known as routers or switches select a path and 
forward, i.e., route, IP datagrams between nodes, or hosts, 
connected to the intemet. For example, intemet 100 com- 
prises multiple networks, including Local Area Networks 
(LANs) 110, 120 and 170, and Wide Area Network (WAN) 
180, interconnected by routers 130, 140, 150 and 160. The 
routers route IP datagrams, for example, between nodes 111, 
112, 121, 122, and 171 via the multiple networks in the 
internet. 

In traditional destination address based routing, a source 
node, e.g., node 111, transmitting an IP datagram to a 
destination node, e.g., node 121, specifies as a destination IP 
address the IP address of the destination node in the IP 
datagram. The IP datagram is encapsulated in a physical 
frame, or packet, and sent to the router attached to the same 
network (LAN 110) as the source node, e.g., router 130 or 
router 140. The router receiving the frame, in turn, extracts 
the IP datagram, and determines the destination IP address. 
The router selects the next hop router enroute to the desti- 
nation node, e.g., router 160, and again encapsulates the 
datagram in a physical frame for transmission to the next 
hop router. This process continues until the IP datagram 
reaches the network to which the destination node is 
connected, i.e., LAN 120, wherein the datagram is delivered 
to the destination node 121. 

Routing tables on each router store information about 
what networks are reachable, either direcdy or via adjacent 
routers. When a router receives an IP datagram, it compares 
the network portion of the IP destination address in the 
datagram, referred to herein as the address prefix, with the 
network reachability information stored in its routing table. 
If a match is found, the router sends the datagram over the 
appropriate, direcdy attached network to the next hop router 
through which the destination network is reachable, or 
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directly to the node, if the destination network is directly 
attached to the router. 

In the event of topological changes to network 100, 
network reachability information may be maintained up to 

5 date, automatically, through the use of an interior gateway 
protocol (IGP), such as the well known Open Shortest Path 
First (OSPF) Version 2 TCP/IP intemet routing protocol, the 
specification of which is set forth in the Internet Standard 
Request For Comments (RFC) 1583, March, 1994. In addi- 
tion to exchanging network reachability information 
between routers, the OSPF protocol routes IP datagrams 
over one of possibly multiple routes based on the destination 
IP address and IP Type of Service specified in the IP header 
of the datagrams. Further details of the well known OSPF 
version 2 routing protocol may be found in RFC 1583. 

Growth of the Internet, as well as private internets, has 
placed demands not only on bandwidth requirements, but 
also the intemet routing protocols and the available IP 
address space. Traditional destination address based routing 

20 using OSPF version 2 generally allows traffic to be routed 
based only on destination IP address and IP type of service. 
New approaches to routing and IP address allocation have 
been sought to improve routing functionality, scalability and 
control as changes in intemet traffic patterns and volume 

25 emerge. 

A particular problem for the Intemet, and for which a 
number of proposals providing short-term and long-term 
solutions have been developed, is running out of imiquc IP 
addresses. One short term proposal is set forth in the 

30 Informational Request For Comments (RFC) 1631, May, 
1994, entitled "The IP Network Address Translator (NAT).^ 
The proposal is based on reuse of existing IP addresses by 
placing NAT software, and NAT tables or databases, at each 
router between routing domains. The NAT table at each 

35 participating router comprises pairs of local, reusable IP 
addresses for use in data packets transmitted within local 
routing domains, and assigned, globally unique IP addresses 
for use in data packets transmitted outside local routing 
domains, that is, over the Internet. 

40 Briefly, network address translation functions as follows. 
With reference to FIG. 1, domains A, B, C and D represent 
separate routing domains. Routing domains A and B are 
stub, or leaf, domains, that only handle traffic originating 
from or destined to hosts in the routing domain, whereas 

45 routing domains C and D route traffic originating from or 
destined to hosts in the same or other routing domains. Most 
of the traffic in leaf routing domains is local, that is, at any 
given lime, generally a small percentage of traffic originat- 
ing from or destined to hosts in a leaf routing domain is 

50 transmitted outside the routing domain. Therefore, the local 
IP addresses assigned to hosts in one leaf routing domain 
may be reused by hosts in another leaf routing domain, 
without IP address conffict. Alocal IP address assigned to a 
host in a leaf routing domain needs only be translated to a 

55 globally unique IP address when the host communicates 
with a host outside the leaf routing domain. Thus, only a 
subset of the local IP addresses used in a leaf routing domain 
are translated to the globally unique IP addresses required 
when transmittmg outside the leaf domain, thereby averting 

60 IP address depletion in the Intemet. 

Routers that provide ingress to or egress from a leaf 
routing domain are known as border routers. Network 
Address Translator (NAT) software, including NAT tables, is 
installed at these routers to provide the network address 

65 translator functionality. For example, routers 130, 140 and 
150 are border routers for leaf routing domains that may 
utilize reusable local IP addresses. 
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According to the proposed NAT solution, host 111 can use is included in an application specific field following the LSA 

a local IP address as the destination IP address when header. LS type 9 LSA packets are used to limit the flooding 

transmitting an IP datagram to host 112. However, host 111 scope to the local network segments attached to the routers, 

must use a globally unique IP address as the destination IP Netwodc address translator information, i.e., ingress IP 

address when sending an IP datagram to a host outside leaf 5 address, ingress port, egress IP address and egress port, are 

routing domain A, e.g., host 121 in leaf routing domain B, transmitted in the application specific field of the Opaque 

viaeitherof routers 130 and 140, say router 130. Router 130 LSA packet. The Opaque LSA packets are exchanged 

checks its routing table, locates the route for the destination between a group of interconnected Opaque LSA capable 

network specified by the globally unique, destination IP routers so that the routers can maintain their NAT tables as 

address, and forwards the IP datagram to the next hop router lo necessary to exchange data packets with routers in other 

via WAN 180, but not before replacing the local IP address routing domains, 

of host 111 in the source IP address field of the datagram ^^.r.^ ^^r* „ , r.,. ™ ^ ^ 
with a globally unique IP address. Ultimately, router 150 ^^^^^ SUMMARY OF THE SEVERAL VIEWS 
receives the IP datagram, and using its NAT software and ™^ DRAWINGS 
associated data stmctures, translates the globally unique 15 The present invention is illustrated by way of example 
destination IP address with the local IP address assigned to and not limitation in the following figures, in which: 
host 121 in routing domain B before forwarding the data- FIG. 1 is a diagram of a data communications internet- 
gram to host 121. work. 

On the retum path, the same process occurs: Host 121, for nG. 2 illustrates the format of an OSPF type 4 packet, 

example, transmits to router 150 an IP datagram destined for 20 3 iUys^rates the fink slate advertisement header 

host 111 in routing domain A, specifying the globally unique ^^hin an OSPF type 4 packet. 

IP address for the host, as determined from the source IP a -u * ^ .1, ^ t oa c ^om- 

address field in the IP datagram that host 121 received from . ™- ^ ff""''' ^P^^^^ ^ ^^^^ 

host 111. The source IP address field in the rettira IP ^^^1 ^/.f 

datagram contains the local IP address for host 121. Router 25 .flG 5 lUustrates an Opaque LSApacket format as may be 
150 replaces the local IP address of host 121 in the source ^^^^^^ ^ embodiment of the present invention, 
IP address field in the datagram with the appropriate globally ^ illustrates a format for a NAT translation table 
unique IP address and forwards the datagram to the next hop maintained in a border router, 
router 160 via LAN 170. Upon receipt of the return IP DETAILED DESCRIPTION OF THE 
datagram at either of router 130 or 140, say router 140, the 30 INVENTION 
globally unique destination IP address for host 111 is trans- 
lated to a locally assigned IP address for host 111, and the Described is a method for distributing Network Address 
datagram forwarded to host 111 Translator (NAT) translation table information within a 
As can be appreciated, and as pointed out in RFC 1631, J^^^^S f .^^i^ .^P^^ ^^^f^^l ^^^^ (^SPF) 
it is very important, if multiple border routers are coupled to 35 Opaq^ie Lmk State Advertisement (LSA) opUon protocol. In 
a particular leaf routing domain, that the network address foUowing descnption, numerous speafic detads are set 
translation tables for each router are identical. In the above ^^'^ P^^^^*?,^ f ^^^^^^^ understandmg of the 
example, note that router 130 accessed its NAT translation P^^^°* "^y^,^^,^^' ^^J'^ ^PP^^'^'' ^^^^^^^^ 
table to translate the locally defined source IP address for ordinary skiU m the art that die present mvention may be 
host 111 to a globally unique source IP address. Router 140 P^^^^f ^^^^^ ^P^^^ ^^^^ instances, 
performed the same but opposite translation when receiving ;^ell-known architectures, steps, and techniques have not 
an IP datagram from host 121 via WAN 180, destined for ^^^^ unnece^nly obscunng the present 
host Ul: it exchanged the globally unique IP address mvenUon. For example specific details are not provided as 
specified in the destination IP address field in the datagram to whether the method is implemented in a router as a 
to a local IP address associated with host 111 before for- 45 software routme, hardware circuit, firmware, or a combina- 
warding the datagram to host 111. If the translation tables for thereof. 

routers 130 and is 140 do not provide identical mappings In alternative embodiments, the present invention may be 
between local and globally unique addresses, there is a apphcable to implementations of the invention in integrated 
likelihood that IP datagrams originating from or desdned to circuits or chip sets, wireless implementations, switching 
hosts in leaf routing domain A do not reach the proper systems products and transmission systems products. For 
destination. Moreover, as the limited set of globaUy unique purposes of this appUcation, the terms switching systems 
IP addresses are shared by the hosts in the routing domain products shaU be taken to mean private branch exchanges 
and therefore the mappings between the globally unique IP (PBXs), central office switching systems that interconnect 
address and the local IP address change over time, depend- subscribers, toll/tandem switching systems for interconnect- 
ing on which hosts are communicating over the Internet at ^5 ing trunks between switching centers, and broadband core 
any given time, it is important that routers 130 and 140 switches found at the center of a service provider's network 
update the other as changes occur to their respective NAT may be fed by broadband edge switches or access 
tables. However, RFC 1631 makes no provision for such multiplexors, and associated signaling, and support systems 
distribution of NAT translation tables between common services. The term transmission systems products shall 
border routers. What is needed, dierefore, is a method of 60 ^ products used by service providers to 
distributing such information. provide interconnection between their subscribers and their 

networks such as loop systems, and which provide 

BRIEF SUMMARY OF THE INVENTION mulUplexing, aggregation and transport between a service 

A method is described for synchronizing Network provider's switching systems across the wide area, and 

Address Translator (NAT) tables among, routers using the 65 associated signaling and support systems and services. 

Open Shortest Path First (OSPF) Opaque Link State Adver- * The present invention is concerned with the particular 

dsement (LSA) option protocol. The NAT table information method or protocol for exchanging Network Address Trans- 
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lator (NPiT) translation table information between adjacent flooded throughout an interior routing area defined by the 

routers. While the description that follows specifically OSPF routing protocol (scope "area-local'^; and type 11 

addresses the method as it applies to IP destination address Opaque LSAs arc flooded throughout an autonomous sys- 

based routing, it is appreciated by those of ordinary skill in tern. As seen in FIG. 5, an embodiment of the present 

the art that the method is generaUy applicable to distribution 5 invention uses type 9 Opaque LSAs to exchange NAT 

of network address translation information between net- translation table information between adjacent Opaque LSA 

works that utilize different network addressing schemes. For capable routers attached to the same local (sub)networks. 

example, the method is equaUy applicable in translating (An Opaque capable router determines wheflier an adjacent 

addresses from one format to another as required for com- router is Opaque-capable through receipt of an OSPF Data- 

munication between heterogeneous network architectures, base Description packet, sent during the Database Exchange 

protocols and addressing schemes. Process, in which the O-bit (Opaque bit) in the options field 

FIG. 6 fllustrates an embodiment of the NAT translation ^^5 is set.) 

table 600 that resides in a border switch or router. The entries ^1^. S illustrates the format of an Opaque LSA packet 500 

shown in FIG. 6 provide mappings as necessary to translate ^ embodied by the present invention. The Opaque LSA 

a local IP address 610 in a leaf routing domain to a globally packet 500 begins with the standard link state advertisement 

unique IP address 620, and vise versa. Since routers have header 305, foflowed by NAT translation table information 

multiple ports, the table also maintains port information contained in fields 505-520. The first field 505 contains a 

identifying the port 605 out which a node, e.g., a host, local IP address, followed by a second field 510 that contains 

having the address is reachable, whether the originating or ^ corresponding globally unique IP address. In an alternative 

destination node. As described above in the background the order of fields 505 and 510 may be 

description of the invention, if a border router receives an IP reversed. The following two fields 515 and 520 are the same 

datagram having a globally unique destination IP address, or the first two fields, and conespond to the next entry in the 

local source IP address, the router checks its NAT translation NAT translation table, i.e., they contain the local IP address 

table for the respective local destination IP address or and globally unique IP address into/firom which the local IP 

globally unique source IP address, and exchanges such ^5 ^^^^^^ ^ translated. The Opaque LSA type 9 packets are 

before forwarding the IP datagram. If there are multiple flooded throughout the hnk-local, i.e., attached network 

border routers for a given leaf routing domain, the NAT segments, in the same manner as other LSAs according to 

translation tables need to be synchronized. A protocol for OSPF protocol. 

doing such is described below. In the network diagram illustrated in FIG. 1, routers 130 

An embodiment of the present invention distributes Net- 30 and 140 exchange NAT translation table information using 

work Address Translator (NAT) translation table informa- the above OSPF Opaque LSA protocol format, 

tion in the above described manner using the Open Shortest Embodiments of the invention may be represented as a 

Path First (OSPF) Opaque Link State Advertisement (LSA) software product stored on a machine-readable medium 

optional protocol. With reference to FIG, 2, the format for an (also referred to as a computer-readable medium or a 

OSPF Link State Advertisement (LSA) packet 200 is illus- 35 processor-readable medium). The machine-readable 

trated. Link state advertisement packets are multicast or medium may be any type of magnetic, optical, or electrical 

broadcast on physical network segments to flood the link storage medium including a diskette, CD-ROM, memory 

state advertisements to adjacent routers in the routing device (volatile or non-volatile), or similar storage mccha- 

domain. Following the OSPF version field 205 is the OSPF nism. The machine -readable mediimi may contain various 

packet type field 210, set to 4. Each LSApacket may contain 40 sets of instructions, code sequences, configuration 

a number of link state advertisements, as indicated in the information, or other data. For example, the procedures 

"#Advertisements" field 215, with the actual link state described above for synchronizing network address transla- 

advertisements 220 following field 215 in the packet. tion tables can be stored on the machine-readable medium. 

As shown in FIG. 3, each link state advertisement 220 Those of ordinary skiU in the art wfll appreciate that oflier 
begins with a 20 byte link state advertisement header 305 45 instmctions and operations necessary to implement the 
that uniquely identifies the link state advertisement. The described invention may also be stored on the machine- 
most recent of potentiaUy multiple copies of the same link readable medium, 
state advertisement are distinguished by the link state age What is claimed is: 

(LS age) field 310 and link state sequence number (LS 1. A method for a border router associated with a routing 
sequence number) field 315. As indicated by the LS type 50 domain to distribute network address translator (NAT) trans- 
field 320, there are multiple types of link state advertisement lation table information to interconnected border routers in 
packets. The contents of LS type field govern the format of the routing domain, comprising the steps of: 
the body of the link state advertisement packet that follows a) inserting the NAT translation table information into an 
the header 305. For example, LS types 9, 10 or 11 indicate Open Shortest Path First (OSPF) Opaque Link Stale 
the Opaque LSA option packet type, the format of which is 55 Advertisement (LSA) packet; and 
Ulustrated in FIG. 4. b) distributing the OSPF Opaque LSA packet to the 

Opaque LSAs 400 begin with the standard link state interconnected border routers, 

advertisement header 305, followed by a 32-bit aligned 2. The method of claim 1, wherein inserting the NAT 

information field 400 that contains application specific infor- translation table information into an OSPF Opaque LSA 

mation which may be utilized by OSPF or other applica- 60 packet comprises inserting the NAT translation table infor- 

tions. Opaque LSAs are flooded throughout the internet in mation into an application specific field of the OSPF Opaque 

the same maimer as other LSAs according to the well-known LSA packet. 

link-state database distribution mechanism used by OSPF. 3. The method of claim 2, wherein inserting NAT trans- 

The contents of the LS type field 320 define the range of lation table information into an application specific field of 

distribution, or flooding scope, for Opaque LSAs: type 9 65 the OSPF Opaque LSA packet, comprises: 

Opaque LSAs are flooded throughout the local network or a) inserting a local network address into a first field of the 

subnetwork (scope "link-local"); type 10 Opaque LSAs are application specific field; and 
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b) inserting a corresponding globally unique IP address 
into a second field of the application specific field. 

4. The method of claim 1, wherein distributing the OSPF 
Opaque LSA packet to the interconnected border routers, 
comprises: 

a) setting the flooding scope for the OSPF Opaque LSA 
packet to local network segments; and 

b) advertising the OSPF Opaque LSA packet to the 
interconnected border routers within the flooding 
scope. 

5. A method for distributing network address translation 
information from a first network device to a second network 
device, comprising: 

at the first network device, providing a data unit that 
includes both network address translation information 
and at least some network topology information, the 
data unit is an Open Shortest Path First (OSPF) Opaque 
Link State Advertisement (LSA) packet; 

transmitting the data unit from the first network device to 
the second network device; and 

at the second network device, employing the network 
address translation information from the data unit to 
update any existing network address translation infor- 
mation. 

6. Hie method of claim 5, wherein the transmitting of the 
data unit step further includes the steps of: 

setting a flooding scope for the OSPF Opaque LSA packet 
to local network segments; and 

advertising the OSPF Opaque LSA packet to intercon- 
nected border network devices within the flooding 
scope. 

7. A data structure embodied in software stored on the 
machine -readable mediimi for distributing network address 
translation information from a first network device to a 
second network device in a computer network, comprising: 

at least one field containing link state information that 
indicates reachability of at least one device in the 
computer network; and 

at least one apphcation specific field that contains Net- 
work Address Translator (NAT) translation table infor- 
mation. 

8. The data structure embodied in software stored on the 
machine -readable medium of claim 7, wherein said network 45 
address translation information includes at least one local 
network address and at least one corresponding globaUy 
unique network address. 

9. The data structure embodied in software stored on the 
machine -readable medium of claim 7, wherein the globally 
unique network address is an Internet Protocol (IP) address. 

10. The data structure embodied in software stored on the 
machine-readable medium of claim 7, wherein the local 
network address is an Internet Protocol (IP) address. 



35 



50 



11. A network device for distributing network address 
translation information to at least one other network device, 
comprising: 

a plurality of ports; 

interconnection circuitry that faciUtates transmission of 
data units between the plurality of ports within the 
network device, the data unit includes an Open Shortest 
Path First (OSPF) Link State Advertisement (LSA) 
packet; 

circuitry that provides a data unit that includes both 
network address translation information and at least 
some network topology information; and 

circuitry that prompts transmission of the data unit to the 
at least one other network device via at least one of the 
ports. 

12. The network device of claim 11, including circuitry 
that places a local Internet Protocol (IP) address into a first 
field of the packet and a corresponding globafly unique IP 
address into a second field of the packet. 

13. The network device of claim 12, wherein the network 
device includes a network border router, 

14. The network device of claim 13, wherein the network 
device includes a network switch. 

15. A method for distributing network address translation 
information from a first network device to a second network 
device, comprising: 

at the first network device, providing a data unit that 
includes both network address translation information 
and at least some network topology information, the 
providing of the data unit includes inserting Network 
Address Translator (NAT) translation table information 
into an application specific field of an Open Shortest 
Path First (OSPF) Opaque Link State Advertisement 
(LSA) packet; 

transmitting the packet from the first network device to 
the second network device; and 

at the second network device, employing the network 
address translation information from the packet to 
update any existing network address translation infor- 
mation. 

16. The method of claim 15, wherein the providing of the 
packet includes: 

inserting a local network address into a first portion of an 
application specific field of the data unit; and 

inserting a corresponding globally unique Internet Proto- 
col (IP) address into a second portion of the application 
specific field. 
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